💡 Motivation and Context

The Python OpenFeature provider rejects hexadecimal variants such as 0x10, while the Node provider accepts them. This difference came up while comparing providers in PostHog/posthog-elixir#214 (comment).

Both Python numeric resolvers now accept unsigned hexadecimal integers with 0x or 0X prefixes. The integer resolver returns an integer and the float resolver returns a float. Decimal parsing, numeric non-string variants, and the original variant metadata are unchanged. Hex values are converted directly to integers without a decimal-string round trip, so large integers are not subject to Python’s decimal conversion digit limit. Values too large for a float return TypeMismatchError. Signed, malformed, fractional, and underscore-separated hexadecimal strings remain type mismatches.

💚 How did you test it?

• Verified eight new valid-hex cases failed before the fix.
• Reproduced four numeric non-string failures and a large-hex-integer failure before the review fixes. Added regression tests for those cases, representable large floats, and float overflow.
• uv run --package openfeature-provider-posthog pytest -q: 68 passed.
• Provider Ruff formatting, Ruff lint, and mypy checks passed.
• Isolated autoreview of the final branch reported no actionable findings.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Implemented with Pi using local file editing, shell tests, and the isolated autoreview helper. The scope is hexadecimal numeric variants only, not full JavaScript number-parser parity. No shared session link is available.